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entitled INTRUSION DETECTION SYSTEM AND METHOD, Serial No. 60/402,255 ("the 
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5. Concurrently herewith, we have submitted a Declaration Under 37 C.F.R. § 1 . 1 31 
("Declaration A"), to establish a conception of the invention disclosed in the Provisiona! and 
claimed in at least the independent claims (claims 1, 21, 40, and 42) in the Application prior to 
July 30, 2002 and certain of the dependent claims (at least claims 2, 5-7, 15, 24-27, 41 and 43) 
that are embodiments of the independent claims, and to establish diligence in reducing the 
invention so claimed to practice between prior to July 30, 2002 and August 9, 2002. This 
Declaration Under 37 C.F.R. § 1.131 ("Declaration B") is also being submitted to establish a 
conception of the invention disclosed in the Provisional and claimed in the Application prior to 
July 30, 2002, and to establish diligence in reducing the invention to practice from before July 
30, 2002 to August 9, 2002. Specifically, this Declaration addresses the subject matter claimed 
in dependent claims 3-4, 8-12, 13-14, 22-23, 28, and 32-34. 

I. EVIDENCE OF CONCEPTION BEFORE JULY 30. 2002 

6. Prior to July 30, 2002, in Westford, MA, we (Danny Lobo and Anil Singhal) 
conceived the invention disclosed in the Provisional and claimed in the Application. More 
particularly, prior to July 30, 2002, in Westford, MA, we conceived of a method for intrusion 
detection as recited in independent claim 1 that further features: 

• "receiving, at a probe, data packets communicated over a third network link", as recited 
in claim 3; 

• "aggregating the data packets received over the first network link and the data packets 
received over the third network link", as recited in claim 4; 

• "maintaining, by the probe, an audit trail buffer for forensic analysis", as recited in claim 
8; 

• the audit trail buffer of claim 8 comprising "a memory for recording monitored packets", 
as recited in claim 9; 
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• the memory of claim 9 "recording] packets from at least one of the first network link and 
the third network link", as recited in claim 10; 

• "receiving, by the probe, an event notification; and upon receipt of the event notification, 
communicating, by the probe, the current contents of the audit trail buffer", as recited in 
claim 11; 

• "storing received packets in a collection buffer; stripping header information associated 
with a protocol of the first network link; and adding header information associated with a 
protocol of the second network link.", as recited in claim 12; 

• the storing step of claim 12 comprising "storing packets received from at least one of the 
first network link and a third network link", as recited in claim 13; and/or 

• "the stripping step [of claim 1 2] further compris[ing] stripping header and checksum 
information associated with a protocol of the first network link; and the adding step [of 
claim 12] further compris[ing] adding header and checksum information associated with 
a protocol of the second network link", , as recited in claim 14. 

7. Prior to July 30, 2002, in Westford, MA, we also conceived of a network 
performance probe system as recited in independent claim 21 that further features: 

• "a third network interface for monitoring packets communicated over a third network 
link", as recited in claim 22; 

• "an aggregator for aggregating the packets from the first network link and the packets 
from the third network link", as recited in claim 23; 

• "a performance analyzer for acquiring network performance data in response to the 
monitored packets communicated over the first network link", as recited in claim 28; 

• "an audit trail buffer maintainable for forensic analysis", as recited in claim 29; 

• the audit trail buffer of claim 29 comprising "a memory for recording monitored packets 
for forensic analysis", as recited in claim 32; 
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• "an event notification receiver for causing the probe, upon receipt of the event 
notification, to communicate the current contents of the audit trail buffer", as recited in 
claim 33; and/or 

• "a collection buffer for storing received packets; a stripper for stripping header 
information associated with a protocol of the first network link; and an adder for adding 
header information associated with a protocol of the second network link", as recited in 
claim 34. 

8. Based on our invention and prior to July 30, 2002, we prepared, in the U.S., 
computer software code, portions of which and printouts of the output for which are attached as 
Exhibits I - R. These Exhibits demonstrate, through use of a software program time stamp 
attached here as Exhibit G, conception of the above-described inventions before July 30, 2002. 

9. The code that we prepared and that is documented in Exhibits G and I - R is an 
implementation of one embodiment of the claimed invention. It comprises a NetScout intrusion 
detection system operating in conjunction with a NetScout probe model 9200 to detect any 
malicious network traffic and network usage which cannot be detected by a conventional 
firewall. 

10. The software programs from which the Exhibits have been extracted contain 
instructions implementing several functionalities that are neither relevant nor useful to 
implement the invention claimed in the Application. Only those portions of the software code 
that are necessary to show the conception of the claimed inventions have been attached as 
Exhibits hereto; the remainder of the software code has been blocked from its respective Exhibit 
to preserve its confidentiality. Because the Exhibits are multi-page documents, when an entire 
page of the Exhibit was blocked, the entire page was deleted from the Exhibit. Also, in 
accordance with MPEP 715.07.11, dates have been blocked from the Exhibits in order to 
preserve confidentiality. We declare that the dates are all prior to July 30, 2002. 
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1 1 . Although other persons contributed to the development of the multiple 
functionalities implemented in the larger software code, portions of which were extracted and 
are attached as Exhibits I - R, Danny Lobo and Anil Singhal were responsible for the 
preparation of the computer software code that implemented the claimed invention, either by 
preparing the code themselves or having the code prepared at their direction. 

A. A third network interface for monitoring packets communicated over a third 
network iink (Claim 22) 

1 2. As shown in Exhibit I, the code includes instructions for providing "a third network 
interface for monitoring packets communicated over a third network link", as recited in claim 22. 
Exhibit I consists of portions of a software program entitled DRVCFG.C, which contains 
instructions to implement the network performance probe system recited in claim 22. Page 1 of 
Exhibit I shows that DRVCFG.C bears a copyright notice in the name of Frontier Software Dev. 
Inc., which was the name of NetScout at the time that the software program DRVCFG.C was 
created. DRVCFG.C identifies the driver "FEC", the driver "CC3i", and the device "IDS." As 
established in Declaration A, the WAN link CC3i is an embodiment of the first network link and 
the Ethernet driver FEC is an embodiment of a second network link, such as recited in 
independent claim 1. DRVCFG.C identifies the Model 9200 probe as being IDS capable to 
allow the IDS device to work as the third network link. The IDS device operates as an 
embodiment of the third network link over which data packets may be transported. 

See, for example, Code Fragment 1 of Exhibit I (page 3): 

#elif (MODEL_9200 && I_IDS) 
#define FEC 1 

#elif (MODEL_92 00 && _IDS) 
#define PEC 1 
#define CC3i 1 
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B Receiving, at a prob e, data packets c o mmunicated over a third network link (Claim 3) 

13. As shown in Exhibits I and J, the code includes instructions for "receiving, at a 
probe, data packets communicated over a third network link", as recited in claim 3. DRVCFG.C, 
described above as Exhibit !, has instructions, "#elif (MODEL_9200 && IJDS)" and "#elif 
(MODEL_9200 && JDS)", that show that the Model 9200 probe is capable of operating in IDS 
and non-IDS mode. The non-IDS mode is a receive-only mode, to allow the probe to receive 
data packets from sources such as the IDS device. Exhibit J consists of portions of a software 
program entitled FECMAIN.C, which implements the Fast Ethernet driver FEC. FECMAIN.C is 
invoked by the data packet converter code to do the function of transmitting/forwarding the data 
packets over the IDS device (the third network link) in communication with the FECMAIN.C 
driver (the second network). The description of the function, "FecRecvFrame", in FECMAIN.C 
shows that data packets are received. See, for example, Code Fragment 2 of Exhibit J (page 
41): 

/****************************** 

* Function: FecRecvFrame. * 

* Description: Receive Packet Handler. * 

If NO pkts are received then info->f rame_size will be * 

* set to ZERO. * 

* Returns: XMIB_FRAME_INFO struct. * 
EXPORT XMIB_FRAME_INFO * FecRecvFrame <ifn) ^ 

14. The comments in FECMAIN.C indicate further that data packets in the form of 
frames are received by the Model 9200 probe from, for example, an IDS based device. See 
also, for example, Code Fragment 3 of Exhibit J (page 43): 

// Check if frame has arrived. 

//A frame can arrive on the High Priority Q or on the Low Prority Q. 
//If non-partial xfr mode is used, frames will arrive on LoPri Q only 
//In partial xfr mode, the header will arrive on HiPri Q and trailer 
// will arrive on LoPri Q. 

// Note: Hi Pri Q <=> Q2 and Lo Pri Q <=> Ql 
// Check the Completion Ql. 
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// Note; In partial xfr mode, only 1 receive completion Q (i.e. Ql) is 
// used. 

SF_READ_REG (CompletionQIProducerlndex, &CompletionQlProducerReg) ; 
SF_READ_REG (CompletionQIConsumerlndex, &CompletionQlConsumerReg) ; 

RxComQProducerlndex = (N16) 

CompletionQlProducerReg . b . RxCompletionQIProducerlndex ; 
RxComQConsumerlndex = (N16) 

CompletionQIConsumerReg .b . RxCompletionQIConsumerlndex; 

if (RxComQConsumerlndex !<= RxComQProducerlndex) 
{ // Frame has arrived 

c - Aggregating t he data packets rece ived over the first network link and the data 
packets received over the third ne twork link (Claims 4. 231 

15. As shown in Exhibit K, the code includes instructions for "aggregating the data 
packets received over the first network link and the data packets received over the third network 
link", as recited in claim 4. Exhibit K also contains instructions for features in claim 23, which, 
though of different scope from claim 4, recites similar elements and was rejected under the 
same rationale. Exhibit K consists of portions of a software program entitled REALCOL.C, 
which contains network performance evaluation code. REALCOL.C provides for processing 
data packets received from both the WAN link driver CC3i (the first network link) and the IDS 
device (the third network link), and for aggregating the data packets so received. REALCOL.C 
has a flag, "LINKAGGR", that demonstrates that aggregation of data is supported, and an 
instruction, "CALL PP PROCESS (MIRRORJFN);", that calls a mirror interface to process the 
packet from both the WAN link driver CC3i and the IDS device. See, for example, Code 
Fragment 2 of Exhibit K (pages 6 - 7): 

#elif (_FEC) | | <_LINKAGGR) 
/* 

** For FEC: do this if only Fast Ether Channel option is on 
** For 8700, 87CC: do this only .if Link Aggrgation is on 
*/ 

if ( (info->mirr__ifn__enabled == TRUE) && (info->ifn > 2)) 

/* save info ptrs. */ 
UINT vifn = info->vifn; 
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UINT lifn = info->lifn; 

UINT lvifn = info->logical_vifn; 

info->vifn = info->lifn = info->logical_vifn = 0; 
CALLJ?P_PROCESS(MIRROR_IFN) ; 

/* retrieve the saved info ptrs. */ 

info->vifn = vifn; 

info->lifn = lifn;. 

info->logical vifn = lvifn; 

} 

#endif // model 73xx, 8200, 8700, 87cc 



D - Maintaining, bv the probe, an audit trail buffer for forensic analysis (Claims 8. 29) 

1 6. As shown in Exhibit L, the code includes instructions for "maintaining, by the 
probe, an audit trail buffer for forensic analysis", as recited in claim 8. Exhibit L also contains 
instructions for features in claim 29, which, though of different scope from claim 8, recites similar 
elements. Exhibit L consists of portions of a software program entitled COLCAPT.C, which is 
used to capture and buffer data that could be used for forensic analysis and as an audit trail. 
The comment of COLCAPT.C, "Capture related structures", show that data are captured, and 
the entry, "CaptureBufferEntry", shows that data are buffered. The buffers that are developed 
by COLCAPT.C are re-usable buffers of a limited number. Once exhausted, they can be 
replenished again. These buffers contain data directly pertaining to the operation performed. 
See, for example, in Code Fragment 1 of Exhibit L (page 2): 
/* 

** Capture related structures. 

** All Packet indices are one-based. 

*/ 

typedef struct 
{ 

CaptureBuf f erEntry_HDR hdr; 

TRACE JBUCKETJHDR * f irst_bucket ; /* first logical bucket ptr */ 

TRACE_BUCKET_HDR * curr_bucket ; /* current used bucket ptr */ 

TRACE_BUCKET_HDR *ret_bucket; /* bucket ptr, used in retrieve */ 
N32 count_bucket; /* no. of buckets in list */ 

N32 packet_index; /* last packet in the buffer */ 

N3 2 c apture_s tart_t ime ; 

/* time (ms) capture started */ 
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N32 max_bufsize; /* Max buffer size allowed */ 

N32 bucket_size; 

/* These fields are used for allocate/commit/release operations. */ 
TRACE_BUCKET_HDR *new_f irst_bucket ; 
N32 new_bucket_count ; 
} CAPTURE_ROOT; 



1 7. COLCAPT.C contains "if-then" instructions for analyzing the captured data. See, 
for example, Code Fragment 5 of Exhibit L (page 10): 



TRACE(RETRIEVE_CAPTURB) ; 

if (keyJLen 1 = key_len) ; /* unreferenced argument */ 

if (key_type == KEY_TYPE_CAPTURE_HDR) 
return (&cr->hdr) ; 

if ( (key_type != KEY_TYPE_CAPTUREJDATA) && 

(key__type 1= KEY TYPE FAST CAPTURE DATA) ) 
{ - - . 

. log_event ( "retrieve_capture : invalid key type %#0 . Six" , 

key_type) ; 

return (0) ; 
} 

/* check if capture has started ? */ 

if (cr->hdr . CapturedPackets == 0) 
return ( 0 ) ; 

if (get_next) 

getnext_id(cr, key_ptr) ; 

id = GET_BE_32 ( (TRN32 *) key_ptr) ; 

if (key_type == KEY_TYPE_FAST_CAPTURE_DATA) 

return { f ast_retrieve_capture (cr, id) ); 



E. The audit trail buffer comprising a memory for recording monitored packets 
(Claims 9, 32) 

18. As also shown in Exhibit L, the code of .COLCAPT.C includes instructions for 
providing "the audit trail buffer compris[ing] a memory for recording monitored packets", as 
recited in claim 9. Exhibit L also contains instructions for features in claim 32, which, though of 
different scope from claim 9, recites similar elements and was rejected under the same 
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rationale. The comments of COLCAPT.C show that it contains instructions for allocating a 
CAPTURE root data base for storing data. The call, "col_activate_capture", operates to initialize 
memory allocation logic. The call, "malloc", is an operating system call for requesting memory 
which is then used for capture logic. See, for example, Code Fragment 2 of Exhibit L (pages 5 - 

6): 

EXPORT BOOL col_activate_capture (handler id, max entry) 
U1NT handler_id; 
UINT max_entry; 

CAPTURE_ROOT *cr; . . 

TRACE (COL_ACTIVATE_CAPTURE) ; 

/* Allocate a CAPTURE root database. */ 
if ((or « malloa (sizeof <CAPTURE_ROOT) ) ) — 0) 
return (FALSE) ; 

/* 

** Invalidate all entries to force OP_CONFIG_COLLECTION to be done 

raemset (cr, 0, sizeof{ CAPTURE_ROOT ) ) ; 
cr->hdr. operation = 0P_C0NFIG_C0LLECTI0N; 
cr->packet_index = l; 

cr~>max_bufsize = { (N32) max_entry) « 10; 

/* Set pointers to collection and retrieval handler functions. */ 

handler_list [handler_id] .collector = collect_capture; 
handler_list [handler_id] .retriever = retrieve_capture; 
handler_list thandler_id] .writer = write_capture; 
handler_list [handler_id] .deactivate = deactivate_capture; 
handler_list[handler_id].stats_ptr = cr; 

return (TRUE) ; 
} 



F - The memory recording packets from at least one of the first network link and the 
third network link fClaim 101 

19. As also shown in Exhibit L, the code includes instructions for providing the 
"memory recordfing] packets from at least one of the first network link and the third network 
link", as recited in claim 10. COLCAPT.C contains instructions for recording packets used for 



10 



Application No.: 10/637,431 
Attorney Docket No. 09851.0006-00000 



forensic analysis and for maintaining an audit trail. The instruction reciting "wanhdr_enabled" 
show that the packets are recorded from the WAN link or CC3i driver. See, for example, Code 
Fragment 3 of Exhibit L (page 6 - 7): 

PRIVATE VOID collect_capture (cr, . framejptr, frame_size, 

frame_status, framejtime, frame_id) 

CAPTURE_ROOT *cr; 
N8 *frame_ptr; 
UINT f rame_size; 
N32 f rame_status ; 
N32 frame_time; 
N32 frame_id; 
. { 

N32 pkt_time; 
CaptureBuf ferEntry *p; 
WAN_MACHDR *wmac = 0; 
ATM_HDR *AtmHdrPtr = 0; 
VLAN_INFO *vlan_info = 0; 
BOOL wanhdr_enabled; 
BOOL PassAttnHeader; 
BOOL PassVlanHdr; 
N8 *dp; 
UINT n, nl; 
N16 size; 

TRACE (COLLECT_CAPTURE) j 

if (cr->hdr. operation 1= OP_START_COLLECTION) 

return; /* Nothing to do, if capture not on */ 

wanhdr_enabled = PassAtmHeader = PassVlanHdr = FALSE; 



20. During the invocation of COLCAPT.C, the captured packets are stored in the 
buffer entry in the memory that was allocated as was described above in paragraph 18. See, 
for example, Code Fragment 4 of Exhibit L (page 8): 



/* Now save the buffer in the bucket */ 

if ( (p = (CaptureBuf ferEntry *) capt_get bufp (cr->curr bucket)) == 0 ) 
{ 

log_event { "collect_capture: NULL buffer ptr provided !\n"); 

return; 

} 

p = (CaptureBuf ferEntry *) ( (N8 *) p + cr->curr_bucket->space_used) ; 
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G An event notification receiver for causing tho nr o be. upon receipt of the event 
notification, to communicate the contents of an audit trail buffer (Claims 11.33) 
21 . As shown in Exhibit M, the code includes instructions for "receiving, by the probe, 
an event notification; and upon receipt of the event notification, communicating, by the probe, 
the current contents of the audit trail buffer", as recited in claim 11. Exhibit M also contains 
instructions for features in claim 33, which, though of different scope from claim 1 1 , recites 
similar elements and was rejected under the same rationale. Exhibit M consists of portions of a 
software program entitled RETPDIR.C, which is a component of an event notification receiver. 
Exhibit M shows instructions for response to an RMON event. The call, "HANDLER RMON 
EVENT", initiates the event notification that will invoke the function, "ret_init_event." Similarly, 
the call, "HANDLE RMON CAPTURE", when initiated, will invoke the function "ret_init_capture" 
for communicating the current contents of the audit trail buffer . See, for example, Code 
Fragment 1 of Exhibit M (page 26): 

case HANDLER JiM0N__CAPTURE ; 

bp = (BufferControlEntry *) p ; 
bp->packet = calloc (PACKET_BUF_SIZE, 1) ; 
if (bp->packet == 0) 
{ 

mib_control_del (p) ; 

return (0) ; 

} 

ret_init_capture (p) ; 
break; 

case HANDLER_RMQN_EVENT : 

ep = {EventEntry *) p ? 
ep-> Community = 0; 

ep- description = calloc {sizeof (N32) 

+ MAX_EVENT_DESC_LEN+1, 1) ; 
if (ep->Description 1=0) 
ep->Community 

= calloc(l, sizeof (N32) 

•+ MAX_EVENT_COMMUNITY_LEN+l) ; 
if ( {ep- description == 0) | | (ep->Community o) ) 

mib_control_del (p) ; 
ret urn (0); 

} - - 

ret_init_event (p) ; 
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break; 

H - A collection buffer for sto ring received packets (Claims 12. 34). the packets 
received from at least one of the first network link and the third network link 
(Claim 131 

22. As shown in Exhibits J, N, and O, the code includes instructions for "storing 
received packets in a collection buffer", as recited in claim 12. Exhibits J, N, and O also contain 
instructions for features in claim 34, which, though of different scope from claim 12, recites 
similar elements and was rejected under the same rationale. Further, the instructions include 
instructions for the storing step to comprise "storing packets received from at least one of the 
first network link and a third network link", as recited in claim 13. The Ethernet driver identified 
as FECMAIN.C (Exhibit J above) contains instructions to implement a buffer for storing received 
data packets. FECMAIN.C includes the call "AllocateAdaptermemory", which allocates memory 
for the collection buffer for the network link. See, for example, Code Fragment 1 of Exhibit J 
(page 31): 

// Allocate memory for descriptors+ buffers for both Rx and Tx 
if (! (AllocateAdapterMemory (Adapter) ) ) 
return (EDRV_CONFIG_FAIL) ; 

// Initialize some variables in the adapter structure 
Adapter- >AvailableTxDesc = SF_NUMBER_OF_TX_DESC; 

Adapter- >PhysicalSegmentThreshold - SF_PHYSICAL_SEGMENT_THRESHOLD; 

Adapter- >TxBuf f ersInUse = 0; 

Adapter ->TxBuf ferlndex = 0; 

Adapter- >DPCQueued = FALSE; 

Adapter- >ResetInProgress - FALSE; 

Adapter- >RxGfpNoResponseInt = FALSE; 

23. Exhibit N consists of portions of a software program entitled FECHW.C, which, in 
conjunction with FECMAIN.C, implements a collection buffer for storing received packets. The 
program defines the above-described memory-allocating call, "AllocateAdaptermemory." See, 
for example, Code Fragment 3 of Exhibit N (page 7): 
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SF_ADAPTER * Adapter; 



UINT ii; 

// 

// Allocate Memory for XMT 
// 

#ifdef ORIGINAL 

UINT PoolBuffersNeeded; 

N32 TmpAddress; 

// We need some NDIS_BUFFERs to describe memory that we 
// allocate (generally either to flush the buffer, or 
// because we need its physical address) . To do this 
//we need a buffer pool, so we have to determine how 
// many buffers we need. 

PoolBuffersNeeded = SF_NUMBER_OFJRX_DESC + SF_MAX__TX_BUFFERS ; 

NdisAllocateBuf f erPool ( 
SAllocStatus, 

&Adap t er - > FlushBuf f er Poo lHandle , 
PoolBuffersNeeded) ,- 

if (AllocStatus != NDIS_STATUS_SUCCESS) { 
return FALSE; 

} 

#endif 



24. Exhibit O consists of portions of the software program entitled CC3iAPi.C, which 
implements the WAN link driver CC3i, which, as noted above, is an embodiment of the first 
network link. CC3iAPi.C contains instructions for receiving the packets from the WAN LINK 
CC3i. The routine "cc3i_recv_frame" is the corresponding routine which performs this function. 
See, for example, Code Fragment 1 of Exhibit O (page 16): 
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** Receive the next frame if any from the specified port. 

** Note : In the current implementation, if a frame size > recv buffer size ... 
and the frame is spread in more than one buffer than only the 
first buffer will have proper data, while the remaining data 

** copied by upper layers will be garbage. !l 

EXPORT XMIB_FRAME_INFO *cc3i_recv_f rame (if n) 
UINT ifn; 
{ 

XMIB_FRAME_INFO *info; 

RXDESCR *fd; 

IOCB *iocb; 

UINT datacnt; 

INT inusejport ; 

BOOL discard; 

N8 frm_status; 

25. The procedure for receiving the packets from the WAN LINK CC3i is found in 
Step 1 and Step 2 of CC3iAPi.C. See, for example, Code Fragment 2 of Exhibit O (pages 16 - 
17): 
/* 

** Step 1 : check if any data present. 
*/ 

if { i (fd->status & USED) ) 

{ 

/* No frame, enable watchdog */ 
check_cc3i_resync (iocb, inuse_port, NO_FRAMES) ; 
return (info) ; 
} 

/* 

** Step 2 : gather length and verify frame is received completely. 

iocb ~ >next_rxout = iocb->rxout; 
discard = FALSE; 
frm__status = fd->status; 
if ((frm_status & EOFRM) && fd->count) 
{ 

datacnt = fd->count; /* add to total count */ 
if (++iocb->next_rxout >= MAXDESC) 
iocb->next_rxout = 0; 

else { 

datacnt = 0; 
do { 

if ( ! (fd-> status & EOFRM) && 

(fd->count != iocb->rxbufsize) ) 
{ ' 
iocb->invalid_f rames++ ; 
discard = TRUE ; 
datacnt - 0 
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} 

26. The program FECHW.C (Exhibit N) includes the instruction "Adapter- 
>RxDescRing[Priority].AIIocSize = ((sizeof(SF_RX_DESC) * SF_NUMBER_OF_RX_DESC)+ 
S F_D ES C_Al_ I G N )" , for initializing the memory. See, for example, Code Fragment 2 of Exhibit 
N (page 3): 



PSF_ADAPTER Adapter; 
UI-NT Priority; • 

{ 

UINT ii; 

if (Priority >= SP_NUMBER_OF__RX_QUEUES ) 

return (TRUE) ; // Do not allocate this descriptor ring 

// Allocate memory to hold the receive descriptors (non-cached) . 
Adapter- >RxDescRing [Priority] .AllocSize = 

( (sizeof (SF_RX_DESC) * SF_NUMBER_OF_RX_DESC) 

+ SF_DESC_ALIGN) ; 

Adapter- >RxDescRing [Priority] .AllocVa - 

(N32) malloc (Adapter- >RxDescRing [Priority] .AllocSize) ; 

Adapter- >RxDescRing [Priority] .AllocPa = 

Adapter- >RxDescRing [Priority] .AllocVa; 

if (! Adapter- >RxDescRing [ Priority] .AllocVa) 
{ 

log_event ("<Error>: Insufficient Memory for Rx 
Descriptors") ; 
return FALSE; 
} 

memset ( (VOID *) Adapter- >RxDescRing [Priority] .AllocVa, 0, 
Adapter- >RxDescRing [Priority] .AllocSize) ; 



i. A stripper for stripping he ader information associated with a protocol of the first 
network link ( Claims 12. 341 
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27. As shown in Exhibits O and Q, the code includes instructions for "stripping 

header information associated with a protocol of the first network link", as recited in claim 12. 

Exhibits O and Q also contain instructions for features in claim 34, which, though of different 

scope from claim 12, recites similar elements and was rejected under the same rationale. 

CC3iAPi.C (Exhibit O), which, as indicated above, implements the WAN link driver GC3i, 

contains instructions to make calls to a function "strip_wanhdr" that operates to delineate or strip 

WAN protocol information from a received data packet. See, for example, Code Fragment 3 of 

Exhibit O (pages 17-18): 

fd » &iocb->rfd[iocb->rxout] ; 
info->frame_p = 0; 

if ( ! (frm_status & CRCE) ) /* 5.0 */ 

strip_wanhdr<fd->datap, datacnt, info); 

else 

{ 

info->f ramejp = fd->datap; 
info->frame_size = datacnt + FCS_LENGTH; 



J - Stripping checksum information associated w i th a protocol of the first network 
link (Claim 141 

28. As shown in Exhibit O, the code includes instructions for "stripping checksum 
information associated with a protocol of the first network link", as recited in claim 14. The 
instructions of CC3iAPi.C (Exhibit O), which were cited in paragraph 27 above to show 
stripping of data packets, also show stripping of Frame Check Sum (FCS) information. See, for 
example, Paragraph 27 for Code Fragment 1 of Exhibit O (pages 17-18). 

K - An adder for adding header informati on associated with a protocol of the second 
network link (Claims 12. 34) 
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29. As shown in Exhibit P, the code includes instructions for "adding header 
information associated with a protocol of the second network link", as recited in claim 12. 
Exhibit P also contains instructions for features in claim 34, which, though of different scope 
from claim 1 2, recites similar elements and was rejected under the same rationale. Exhibit P 
consists of portions of a software program entitled DECAP.C, which contains calls to packet 
converter code for transforming header information into Ethernet header information. As noted 
above, the FEC driver, which is a Fast Ethernet driver, is an embodiment of the second network 
link. See, for example, the description of the DECAP.C program in Code Fragment 1 of Exhibit 
P(page1): 

/* Description: 

*/ 

/* 

*/• 

/* Contains all functions pertaining decapsulating WAN header & making */ 
/* the packet look like an EThernet frame. 
*/ 

/* 

30. DECAP.C also contains instructions for attaching a MAC header which will then 
be converted to a format suitable to the Ethernet FEC driver. See, for example, Code Fragment 
2 of Exhibit P (pages 23-24): 



/* 

** function builds the proper protocol frame, adding the Ethernet MAC header. 
*/ 

PRIVATE VOID build_x25_etpkt(dp, svc) 
N8 *dp; 
SVC *svc; 
{ 

N16 length; 
N16 etype; 

wmac->xfptr = 0; 

HTON16 ( (TRN16 *) &machdr[4] , svc->vc) ; 
etype = svc->protocol; 

/* first check if this is a multiprotocol VC */ 
if (etype == X25_MULTI_PR0T0C0L) 
{ 
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etype = x25_guess__protocol (dp) ; 
if ( I etype ) 
return; 

} 

else if ((etype == X25_BAY_QLLC) |) {etype == X25_CISCO_QLLC) ) 

SAVE_WAN_HDR ( dp+2 ) ; 
-dp; 

memcpy ( dp , sna_ll chdr , 3 ) ; 

length = wmac->wanf size - wmac->hdrlen + 17; 
POT_BE_16 ( (TRN16 *) (dp - 2) , length); 
wmac->xfptr = dp - 14; 
memcpy (wmac - >xfptr, machdr, 12); 

else if (etype == X25 SNA) 
{ 

SAVE_WAN_HDR (dp) ; 
dp -= 3; 

memcpy (dp, sna_llchdr, 3); 

length = wmac- >wanf size - wmac->hdrlen + 17; 
PUT_BE_16 ( (TRN16 *) (dp - 2), length); 
wmao>xfptr = dp - 14; 
memcpy (wmac- >xfptr, machdr, 12); 

else if (etype == X25_OSI) 

dp -= 3; 

memcpy (dp, osi_llchdr, 3) ; 

length = wmac ->wanf size - wmac->hdrlen + 17; 
PUT_BE_16 { (TRN16 *) (dp - 2), length); 
wmac->xfptr = dp - 14; 
memcpy (wmac- >xfptr, machdr, 12); 

else if (etype X25 BAY PTOP) 
{ - ~ 

S AVE_WAN_HDR ( dp ) ; 
wmac->xfptr = dp; 

else if (etype != NULL PID) 

{ 

SAVE_WAN_HDR(dp) ; 

HTON16 ( (TRN16 *) (dp-2) , etype) ; 

wmac->xfptr = dp - 14 ; 

memcpy (wmac ->xfptr, machdr, 12); 



31 . DECAP.C also contains instructions for transforming the MAC headers into a 
format suitable to the Ethernet FEC driver. See, for example, Code Fragment 3 of Exhibit P 
(pages 33-34): 
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/* 

** function strips out WAN headers, transforms MAC headers and gets 
** encapsulated LAN data for upper layer functions to work on. 

EXPORT VOID strip_wanhdr{datap, length, ' frame_info) 
NB *datap; 
UINT length; 

XMIB_FRAME_INFO * frame info; 
{ 

/* PROTO_PARSER pfn; */ 
TRN16 *len; 

if(datap==o) /* 5.0 */ 

{ 

frame_info->frame_p = 0; 
frame_info->frame_size = 0; 
return; 
} 



L. Adding che cksum information associated with the protocol of the second network 
link (Claim 14): 

32. As shown in Exhibits N and O, the code includes instructions for "adding 
checksum information associated with the protocol of the second network link", as recited in 
Claim 14. CC3iAPi.C (Exhibit O), which, as indicated above, implements the WAN link driver 
CC3i, contains instructions, "info->realJrame_size = datacnt + FCS_LENGTH" and "info- 
>mac_errors = info->crc_align_error = (frm_status & CRCE)", to add Frame Check Sum 
information and delimiters and to mark frames with bad check sums with indicators. See, for 
example, Code Fragment 4 of Exhibit O (page 18): 

if- (info->f rame_p) 

/* Add FCS + start & ending delimiters, 1 byte each */ 

info->real_frame_size = datacnt + FCS_LENGTH ; 

/* info->frame_size = datacnt + length_pad - length_strip; */ 

info- >mac_errors = 

info->crc_align_error =. (frm_status & CRCE) ; 

if (info->dlci_valid) 

xmib_setup_dlci_parms{info) ; 
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else 

info->et_collisions = iocb->stats->rx_abort; 

/* call RMON stats collector */ 
xmib_collect_wanstats(info) ; 

info->f rame_time_ms = timer_get_uptime ( ) ; 

++locb->processed frames; 

} 

33. The program FECHW.C (Exhibit N) includes a header appending function to 

append the CRC or Check Sum for a data packet before the packet frame is transmitted into the 

network. See, for example, Code Fragment 4 of Exhibit N (page 19): 

EXPORT BOOL XmtFrame (Adapter, TxBuffer, Buf f erLength, CRCAppend) 
PS P_ADAPTER Adapter; // Adapter Pointer 
N8 *TxBuffer; // Pointer to the frame to be xmted starting 

// from DA. 

UINT BufferLength; // Lengh of xmt buffer 
N8 CRCAppend; // if TRUE, CRC will be appended before xmting 

34. FECHW.C (Exhibit N) also includes instructions for appending the CRC for a 
data packet. See, for example, Code Fragment 1 of Exhibit N (page 2): 

Adapter- >TxDesc [Priority] [ii] - >u . DWORD0 . CrcEn = 1; // calc. CRC 
See also Code Fragment 5 of Exhibit N (page 20): 

TxDesc->u.DWORD0. CrcEn = (CRCAppend) ? 1 : 0; 

M. A perform ance analyzer for acquiring network performance data in response to 
the monitored packets communicated over the first network link (Claim 28) 

35. As shown in Exhibit K, Q and R, the code includes instructions for providing "a 
performance analyzer for acquiring network performance data in response to the monitored 
packets communicated over the first network link", as recited in claim 28. Exhibit K consists of 
portions of a software program entitled REALCOL.C, which, as indicated above at paragraph 
15, contains network performance evaluation code. REALCOL.C contains code in which 
network performance data is collected into MIB's (Management Information Bases), 
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REALCOL.C contains an instruction, "EXPORT VOID mibmgr_collector(info)", which collects 
data. It also has instructions, "TRACE(MIBMGR_COLLECTOR)" and 
"fastpath_process_frame(info);." MIBMGR_COLLECTOR invokes fastpath_processJrame, 
which acquires data in accordance with the program FASTPATH.C, which is described below. 
See, for example, Code Fragment 1 of Exhibit K (page 6): 



EXPORT VOID mibmgr_collector (info) 
XMIB_FRAME INFO *info; 
{ 

if ( mibmgr_inited == FALSE) 
return ; 

#if _QOS 

IMPORT BOOL xmib_qos_enabled; 
IMPORT BOOL isFramelP; 
IMPORT N8 ipv4Tos; 
UINT qosifn; 

BOOL collect_qos_info = FALSE; 

#endif 

TRACE (MIBMGR_COLLECTOR) ; 

if (info->channel) 
{ 

/* setup channel interface indexes */ 
info->ifn = info->channel->ch__ifn; 
info->lifn = inf o->cnannel->ch lifn) 

} . 

fastpathj?rocess_frame(info) ; 



36. Exhibit Q consists of portions of a software program entitled FASTPATH.C, 
which contains code for acquiring network performance data. It also contains flow management 
and caching functions to speed up collector processing of the data. See, for example, Code 
Fragment 1 of Exhibit Q (pages 4-5): 

EXPORT VOID fastpath_process_frame{XMIB_FRAME_INFO *frame_info) 

PPJDUTPUT *pp_info; 
UINT i; 

CACHE_DATA *free_j>; 
CACHE_DATA *p; 
N8 *packet; 
IMPORT BOOL mib_conf ig_dsmon; 
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IMPORT BOOL mib_conf ig_hcrt; 
IMPORT BOOL mib_conf ig_art; 

/* Parse the frame. */ 

if (frame_info->ifn != MIRROR_IFN) 

{ . 

pp_process_frame<frame_info) ; 

pp_info = (PP_OUTPUT *) frame info->pp info; 

} 

else // Handle the mirror ifn 49 

{ 

pp^info a (PP_OUTPUT *) frame_info->pp_info; 

pp_info->ifn = MIRROR IFN; 

} 

ttif _CDP 

/* Do any CDP processing. 

** GGN: For 8800, CDP Pkts are received on the 
** Channels ranging from 2048 - 2303 

*/ 

if ( pp_info->ig_cdp &&. ( (f rame_info->ifn < LOGICAL_IFN_SEED) 

II 

( (frame_info->ifn >= CHIFNJ3EED) && 

(frame_info->ifn < CHIFN_DTE_SEED) ) } 

) 

col_process_cdp(frame_info) ; 

#endif // _CDP 

/* Special fastpath processing for udp and tcp frames only. */ 

if { ! (pp_info->is_tcp | | pp_info->is_udp) ) 

col_process_rmon2_output (frame_info) ; 

return; 

} 

37. Exhibit R consists of portions of a software program entitled COLETST.C, which 
is invoked by FASTPATH. C for performing the data collection. COLETST.C has an instruction, 
"collect_wanstats", that collects statistics from the data communicated over the- WAN link driver 
CC3i (the first network link). See, for example, Code Fragment 1 from Exhibit R (page 9): 



/* 

* * collect__wanstats ( } 

** This is the RMON-MIB WAN (ether) Stats group collection handler. 

*/ 

PRIVATE VOID collect_wanstats (es, frame_ptr, frame_size, f rame_status, 

frame_time/ frame_id) 
EtherStatsEntry *es; 
N8 *frame_ptr; 
UINT frame_size; 
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N32 f rame_status ; 
N32 frame_time; 
N32 frame_id; 
{ 

#ifdef _WAN 

N64 *p; 
ETHERSTATS_ENTRY *ES; 
XMIB_FRAME_INPO *info; 

if (frame_time != frame_time) ; /* these args aren't used +/ 

if {frame_id 1= f rame_id) ; 

/* 

** Octets & Packets are incremented by frame count amount, since 
** in netflow the frame count may be more than 1, which is default 
** for all other interfaces. 

*/ 

es->Octets += mibcol_curr_octets; 
es->Pkts += mibcol_curr_j>kts ; 



N. Software run time-stamp 

38. Exhibit G is a printout of the output of a software program entitled LINKTIME.C, 
which operates as a time-stamp, evidencing the execution of the software of Exhibits I - R prior 
to July 30, 2002. The date itself has been blocked to preserve its confidentiality in accordance 
with MPEP 715.07.11, but we declare that the time-stamp date was prior to July 30, 2002. 

39. The probe and intrusion detection method disclosed in the computer software 
code shown in Exhibits I - R form the subject of the above-identified application. As can be see 
from the above, substantially all of the features set forth in claims 3-4, 8-12, 13-14, 22-23, 28, 
and 32-34 of the above-identified application are also described in the computer software code 
and printout of the system implementation shown in Exhibits G and I - R. In our opinion, the 
computer software code shown in Exhibits I - R and the printout of the output of the 
LINKTIME.C program shown in Exhibit G, which are dated prior to July 30, 2002, conclusively 
demonstrate the conception of the claimed invention prior to July 30, 2002, and acts supporting 
such conception in the U.S. 
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IS. DILIGENCE FROM JULY 30, 2002 TO AUGUST 9. 2002 

40. Prior to July 30, 2002, a patent application drafting project was started for this 
invention. The project resulted in the filing of the Provisional on August 9, 2002. The law firm 
handling patent matters on behalf of NetScout assigned Docket No. FSD-004 to the Provisional. 
On and after July 30, 2002 and prior to August 9, 2002 (the filing date for the Provisional), a 
draft of the Provisional was being revised. 

41 . As evidence of such work, attached hereto as Exhibit H is a copy of a portion of 
the law firm's invoice to assignee NetScout showing the attorney hours spent on reviewing and 
revising the draft Provisional. As evidenced by the attached copy of selected pages of the 
invoice, on July 25 and 26, 2002, 1 1.50 hours of attorney time were spent on matters on behalf 
of the assignee NetScout including a review and revision of the draft application for FSD-004. 
Thereafter, 4.25 hours of attorney time were spent on July 30, 2002 reviewing correspondence 
from Danny Lobo and conferring with Danny Lobo about the draft Provisional. Further, on 
Friday, August 2, 2002, 0.50 hours of attorney time were spent reviewing a document from 
Danny Lobo. After a break for the weekend, August 3-4, 2002, on Monday, August 5, 2002, an 
additional 4.00 hours of attorney time were spent reviewing Danny Lobo's document and 
revising the application. On August 6, 2002, 0.50 hours of attorney time were spent reviewing 
the application and, on August 7, 2002, 2.00 additional hours of attorney time were spent 
reviewing and revising the draft Provisional, which was filed two days later. 

42. Clearly, the hours that Danny Lobo spent in reviewing versions of the draft 
Provisional in that period would be in addition to those hours of attorney time that were 
documented in Exhibits H. 

43. In our opinion, the copy of a portion of the law firm's invoice to NetScout that is 
attached hereto as Exhibit H and that shows significant work performed in drafting the 
provisional patent application upon which the instant application is based in the period between 
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July 30, 2002 and August 9, 2002 conclusively demonstrates that we were diligent in achieving 
reduction to practice of the invention after July 30, 2002 but before August 9, 2002. 

44. We declare further that all statements made herein of our own knowledge are 
true and that all statements made on information and belief are believed to be true; and further, 
that the statements were made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code, and that such willful false statements may jeopardize the validity of the 
application or any patents issuing thereon. ^^-Ybfe? 
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char nsagent_Jinktime[] . " linktime.c. 
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Testa, Hurvvjtz & Thibeaulx up 



Exhibit H 



Netscout Systems, Inc. 



Invoice: 197095 
Page 13 

07/25I2662~'wm 



FSD-004: review and revise draft; confer 
Martinson regarding draft 



(FSD-004) Incorporated the comments 
from Mr. Lobel Into the application. 
Updated the application and figures with 
Mr. Heffan comments. Drafted e mail to 
MrrL^trapuoTicaUonT 




(FSD-004) Reviewed agent manual 
disclosure. Incorporated Mr. Frank's 
comments into the application. Office 
conference with Mr. Heffan re: 
application. Drafted email to Mr. Lobel 
re: draft application. 




FSD-004: review correspondence from 
Lobo; telephone conferences with Lobo 
to review application draft 




(FSD-004) Telephones conference with 
Mr. Heffan and Mr. Lobel re: draft 



EXHIBIT I 




Description: 

Mn^ a h« S f - driY ? r w Con 1 : ' i9urat ' ion i nf ° for all models 
Must be compiled using appropriate mooel_xxxx switch. 
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#e1if (MODEL_9200 && !_IDS) 
#define FEC 1 

#e1if (MODEL.9200 && _IDS) 
#define FEC 1 
#define CC3i 1 



Code Fragment 1 
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Exhibit J 



Copyright (c) 
Netscout systems, inc. 

westford, ma 01886 
All Rights Reserved ' 

' This software is part of Licensed material, which is the property of 1 

' Netscout Systems, Inc. Unauthorized use, duplication or distribution j 

' is strictly prohibited by Federal law. No title to and ownership of 5 

' this software is hereby transferred. < 



' Module Name : FecMain.C 1 

* component of: Fast Ethernet driver using the Adaptec starfire adapter ' 

• Description: Contains the driver entry point functions conforming to * 

'drvapi' as defined by FSD. 1 



' Revision History: 

•■ vers. Date who why 
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// Allocate memory for descriptors* 
if (! (All ocateAdapterMemory (Adapter; 




return (edrv_config_fail) ; 

// initialize some variables in the adapter structure 
Adapter->AvailableTxoesc = sf_number_of_tx_desc; 
Adapter->Physica1segmentThreshold = sf_physical_segment_threshold; 
Adapter->TxBuffersInUse =0; 
Adapter->TxBufferlndex = 0; 
Adapter->DPCQueued = FALSE; 
Adapter->ResetlnProgress = FALSE; 



Adapter->RxGfpNoResponselnt = FALSE; 



Code Fragment 1 
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* Function: FecRecvFrarae. * 

* Description: Receive Packet Handler. * 

* If NO pkts are received then info->frante_size will be 4 
set to ZERO. * 

**S*i**S*i*****^ M J B - FRAME - INfro struct - * 

EXPORT XMIB_FRAME_INFO *FecRecvFrame (ifn) * ********/ 

Code Fragment 2 
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// Check if frame has arrived. 

// a frame can arrive on the High Priority Q or on the low Proritv o 

// wil? arrive S LoPri q ^ ^ arHve ° n HiPH Q ^nd trailer 

// Note: Hi Pri q <=> Q2' and Lo Pri q <=> qi 
// Check the completion qi. 

// used 1 IP parTial xfr mode ' onl V 1 receive completion q (i.e. QI) is 
SF_READ_REG(Comp1etionQlProducerlndex, ACorapletionQlProducerReq) : 
SF_read_reg (compl eti onQlconsumermdex, &CompletionQlconsumerReg) ; 
RxcoraQProducerlndex = (N16) 

Compl eti onQlProdu cer Reg . b . Rxcompl eti onQIProducerlndex • 
RxComQConsumerlndex = (N16) 

Compl eti onQlConsumerReg . b . Rxcompl eti onQlConsumerlndex ; 

if (RxComQConsumerlndex != RxcoraQProducerlndex) 
{ // Frame has arrived 

Code Fragment 3 
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#defme rmoni_changes_for_rmon2 1 ea1co1 -c 
#defme mcast_bcast_fix i 

* WARNING 

* Copyright (c) 

t NetScout Systems, inc 

Westford, MA 01886 
All Rights Reserved 



* File Name : real col .c 

* Component of: MIB Manager 

* Programmer : Anil singhal 



* Description: 

* Contains all top-level collector functions for Lies, 
includes all channel and filter related functions also 



* Revision History: 

* Vers. Date who why 




Page 1 



EXHIBIT K 



export VOID n)ibmgr_collector(info) 

XMIB_FRAME_INFO *info; 

if C mibmgr_inited = false") 
return; 

#if _QOS 

IMPORT bool xmib_qos_enabled 
IMPORT BOOL isFrameip; 



#endif 



xiMruiM owl ibi-rani' 
IMPORT N8 ipv4Tos; 
UINT qosifn; 
BOOL collect_qos_info = false; 

TRACE (MIBMGR_COLLECTOR) ; 
if (info->channel) 

/"setup channel interface indexes */ 
info->ifn - info->channe"!->ch_ifn; 
info->lifn = info->channel->ch_lifn; 

' Code Fragment 1 

fastpath_process_frameCinfo); 



#e1if^C_FEC) || C—LINKAGGR) 

** For 8700, 87CC: do this only if Link Aggrgation is on 
if (Cinfo->mirr_ifn_enab1ed == true) && {info->ifn > 2)) 

Code Fragment 2 



EXHIBIT K 



UINT lifn = info->lifn; 

UINT lvifn ■ info->1ogical_vifn; . 

info->vifn = info->1ifn - info->logica'l_vifn = 0; 
CALL_PP_PR0CESS(MIRROR_IFN) ; 

/* retrieve the saved info ptrs. */ 



73xx, 8200, 8700, 87cc 




Code Fragment 2 
(Continued) 



#endif // model 
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colcapt.c 



WARNING 

Copyright (c) 
Frontier Software Development Inc. 
Tewksbury, MA 01876 
All Rights Reserved 

This software is part of Licensed material, which is the property of 
Frontier Software Development inc. unauthorized use, duplication or 
distribution is strictly prohibited by Federal law. No title to and 
ownership of this software is hereby transferred. 



************************************* 

COPYRIGHT (C) FRONTIER SOFTWARE DEV. INC 

ALL RIGHTS RESCRVED 

Module Name : colcapt.c 

Component of: NETscout Lie software 

Programmer : Rajeev Nadkarni , Anil Singhal 

Description: Contains all data and functions pertaining to the 
RMON-MIB data capture group: 

- col_activate_capture() 

- deactivate_capture() 

- collect_captur«0 

- retrieve_capture() 

- write_capture() 

Comments: 

Revision History: 

vers. Date who why 
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* Capture related structures. 

* All packet indices are one-based. 



typedef struct 
{ 



CaptureBufferEntry_HDR „„, 
trace_bucket_hdr *f i rst_bucket ; 
trace_bucket_hdr *curr_bucket • 
TRACE_BUCKET_hdr *ret_bucket; 
N 32 count_bucket; 
N32 packet_index; . ._ 

N3 ^ capture_start_time; 

> bucket sl - 2e . maX - bufsi2e = ^ SSTbSSr^lfSSr 

N32 new_bucket_count; 

} CAPTURE_ROOT; 



/* first logical bucket ptr */ 
/* current used bucket ptr */ 
/* bucket ptr, used in retrieve */ 
/* no. of buckets in list */ 
/* last packet in the buffer */ 



Code Fragment 1 
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UINT max_entry; 

CAPTURE_ROOT *cr; 

TRACE (COI — ACTIVATE_CAPTURE) ; 

/* Allocate a capture root database. */ 
if CCcr = ma11oc(si2eofCCAPTURE_ROOT))) = 0) 
return (FALSE) ; 

/* 

** invalidate all entries to force op_config_collection to be done 

memsetCcr, 0, sizeof<CAPTURE_RCX)T)) ; 
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cr->Sacke?!ind^Vl° P - C0NFIG - C0LLECTI0N; 
cr->max_bufsize =~((N32) max_entry) « 10; 

/* Set pointers to collection and retrieval handler functions, 
hand! er_l i st [handl er_i d" 
hand! er_l i st [handl er_i d' 
handl er_l i st [handl er_i d' 
hand] er_l i st [handl er_i d = 
handl er_l i st [handl er_id' 



.collectors col1ect_capture- 
•retriever = retrieve_capture- 
.writer . write_capture; 
-deactivate = deacti vate_captur 
.stats_ptr = cr; 



Code Fragment 2 
(Continued) 



PRIVATE VOID collect_capture(cr, frame_ptr, frame size, 

CAPTURE_ROOT *cr; ^an,e_status, frame_ti me , frame_id) 

N8 *frame_ptr; 

UINT frame_size; 

N32 frame_status ; 

N32 frame_time; 

N32 frame_id; 

{ 

N32 pkt_time; 
CaptureBufferEntry *p; 
WAN_MACHDR *wmac = 0; 
ATM_HDR *AtmHdrPtr = 0: 
VlAN_INFO *vlan_info = 0; 
bool wanhdr_enabled; 
BOOL PassAtmHeader ; 
BOOL PassvlanHdr; 
N8 *dp; 
UINT n, nl; 

N " size; Code Fragment 3 

TRACE (COLLECT_CAPTURE) ; 

Page 6 



EXHIBIT L 



if (cr->hdr. operation != OP_5TART_COLLECTION) 

return; /* Nothing to do, if capture not on */ 

wanhdr_enabled = PassAtmHeader = PassVlanHdr = FALSE; 

Code Fragment 3 
(Continued) 
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* now save the buffer in the bucket ■ 



f C (P - (CaptureBufferEntry *} capt_get_bufp(cr->curr_bucket)) — 

retUrn^ ntC " C ° 11eCt - CaptUre: NULL buffer ptr P rov "ided !\n"); 
} 

- (CaptureBufferEntry *) C( N8 *) p + cr->curr_bucket->space_used) ; 



Code Fragment 4 
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TRACE (RETRIEVE_CAPTURE) ; 

if (key_len != key_len); /* unreferenced argument */ 

if (key_type == key_.type_capture_hdr) 
return(&er->hdr); 

if CCkey type != key_type_capture_data) && 

Ckey_type 1= key_type_fast_capture_data)) 

1og_eventC"retrieve_capture: invalid key type %#0.81x 
return (0); key - 

/* check if capture has started ? */ 



if (get_next) 

getnext_id(cr, key_ptr) ; 

id - get_be_32C(trn32 *) key_ptr); 

if (key_type — KEY_TYPE_FAST_CAPTURE_DATA) - . - 

returnC fast_retrieve_capture(cr, id) ); Code Fragment 5 
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#define LUFTHANSA 1 retpdir.c 
fdefine MIB_LAST_REO_0fCFlx 1 

/SSlISS^^Sf J^g£5gSS_MAP_SUPP0RT 1 

* WARNING 

* Copyright CO 

Netscout systems, inc. 

* westford, ma 01886 

* All Rights Reserved 



] ?«lco?rsyslems7^ the BWjy of 

is Strictly prohibited by Federal llw d " P L lca P on ° r distribution 
J this software is hereby transferred * t0 and own ershi P of 



* Module Name : retpdir.c 
component of: mib Manager 
Programmer : Anil singhal 

Description: 

Retrieval routines for the RMON2 protocol directory group. 
Comments : 
Revision History: 
vers. Date who why 
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if Cbp ->packet == 0) 

raib_control_del Cp) ; 
return(O) ; 

ret_init_capture(p) ; 
break; 

case HANOLER_RMON_EVENT: 

ep = CEventEntry *) p; 
ep->Comraum'ty = 0; 

ep~>Descri prion - callocCsizeof (N32) 

+ MAX_EVENT_DESC_LEN+1,1); 

if (ep->Description ! = 0) 
ep->Comraunity 

= ca1loc(l.sizeof(N32) 

+ MAX_£VENT_COMMUNITY_LEN+l) ; 

if C (ep->Descri prion = 0) || (ep->Commumty — 0) ) 

mib_contro1_de1 (p) ; 
return(O) ; 

brlik? it - eVent(P) 1 Code Fragment 1 



Page 26 



EXHIBIT N 



* copyright (c) , NetScout Systems Inc. 

* ALL RIGHTS RESERVED 

* Module Name : FecHw.c 

* component of: Fast Ethernet driver using the Adaptec Starfire adapter 

* Description: Contains hardware specific funtions that are needed to: 

o a I locate Memory for Receive/transmit * 

* o Program the starfire CHIP. < 

* It does not contain code specific to the PHY Ce.q. for * 

* auto-negotiation) < 

* Compilation: - To be compiled with D8=P and pragma=pack options ' 

- The transmit logic can be disabled by undef'inq * 
TRANSMIT (in FECmain.h) for Debug purposes * 

Tunable parameters: - # of receive Buffers Cset to ??? in ) * 

- size of Rx Buffers set to ?? (in ??.h) * 

- PCI Latency timer (set to ?? elks in ??.h) * 

Debug options: - Debug messages for individual driver entry fns * 

can be turned ON/OFF (via flags in FECmain.c) * 

Note: While making an official release define * 

"RELEASE" in FECmain.h to turn off all DEBUG * 

messages . * 

Revision History: * 

vers. Date who why * 



*************!******< 
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Adapter->TxDescCPn'ority][ii]->u.DWORDO.Crc£n = 1; // calc. CRC 

Code Fragment 1 
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* Function: InitializeReceiveDesc***********' 



pbwte g^inuijiig S eiv«,LTwS ;"";;:;,";,*" — / 

uint Priority; 
UINT ii; 

if (Priority >= sf_number_of_rx_queues) 

return(TRUE); // do not allocate this descriptor ring 

Cnon-cac^). 

Adapter->RxDescRing[Priority] .Allocva = 

malloc CAdapter->RxDescRing[Priority].AllocSize); 

Adapter->RxDescRing{Priority].AllocPa = 
Adapter->RxDescRi ng [Priority] . a! 1 ocVa ; 

if C!Adapter->RxDescRing[Priority] .AllocVa) 

return fIIse^ C " <Error>: Insufficient Memory for rx Descriptors"); 
. } ' 

memset ((VOID *)Adapter->RxDescRingfPriority] .AllocVa, 0 
Adapter->RxDescRlng[Priority].Allocsize5; 

Code Fragment 2 
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* Function: AllocateAdapterMemory 

* Description: Allocates memory required for: 

* - Transmit descriptors and completion queue 

- Transmit buffers (copy buffers for fragmented packets 

* - Receive descriptors and completion queue 

* - Receive buffers and their flush buffers 

* - Structures to map xmt ring entries back to the packets 



EXPORT BOOL AllocateAdapterMemory (Adapter) 
SF_ADAPTER *Adapter; 

UINT ii; 

// 

// Allocate Memory for XMT 
// 

#ifdef ORIGINAL 

UINT PoolBuffersNeeded; 

N32 TmpAddress; 

// we need some NDIS_BUFFERs to describe memory that we 
// allocate (generally either to flush the buffer, or 
// because we need its physical address). To do this 
// we need a buffer pool, so we have to determine how 
// many buffers we need. 

PoolBuffersNeeded = SF_number_OF_rx_DESC + sf_max_TX_BUFFERS; 

NdisAllocateBufferPool ( 
&Allocstatus, 

&Adapter->Fl ushBuf f erPool Handl e , 
PoolBuffersNeeded) ; 

if (Allocstatus != NDIS_STATUS_SUCCESS) { ^ . p. 

return false; bode I-ragment 6 

#endif 



EXHIBIT N 



export bool XmtFrame (Adapter TxBuff*r , 

N8 *TxBu?f er^" Ad3Pter l // Ad f ^te B r U Sfn r I n r 9th ' CRCAPP ^ 
// punter to the frame to be x.ted st, 

// it true, crc will be appended befon 



Code Fragment 4 
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TxDesc->u. D wo RD0 .crc E n - (CRCAppend) ? i : 0; 

Code Fragment 5 
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-' a ySE_RE5ERVED_MEMORY 
Copyright (c) 



* Module Name: cc3iapi c 

• Component of: C C3i, HSSI drivei 
: Programmer: Rajeev Nadkarni. 



/* Description: 

/* Revision History: 

/* vers. Date who why 
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** Notr^in h the e cSrrIn?%ir i any from the specified port. 

^ copied by upper layerl SlTbe garbage l!^ remai «""9 data 

export XMIB_FRAME_info *cc3i_recv_f rame(i f n) 
uint i n; 

XMIB_FRAME_INFO *info" 
RXDESCR *fd; 
IOCB *iocb; 
uint datacnt; 
INT inuse_port; 

bool discard; Code Fragment 1 

N8 frnustatus; 



/* 

** Step 1 : check if any data present. 

if ( ! (fd->status & USED) ) 

/* No frame, enable watchdog */ 
retum(info)^ SynC<: ' iOCb ' inuse -P° rt - no_frames); 

/* 

** Step 2 : gather length and verify frame is received completely. 

iocb->next_rxout = iocb->rxout; 

discard = false; 

frm_status = fd~>status; 

if ((frrrustatus & eofrm) && fd->count) 

datacnt =fd->count; /* add to total count •/ 
it C++iocb->next_rxout >= maxdesc) 
Page 16 
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iocb->next_rxout = 0; 



datacnt = 0 
do { 



i f C ! (f d->status & eofrm) && 

Cfd->count 1= iocb->rxbufsi 2e )) 

iocb->inva1id_frames++; 
discard = true ; 

datacnt - 0; Code Fragment 2 

(Continued) 



fd = «iocb->rfd[iocb->rxout] : 
i nfo->f rame_p =0; 

Page 17 



else 

{ 



EXHIBIT O 



info->frame_p = fd~>datap- 
info->frame_size = datacnt • 



FCS_LENGTH; 



Code Fragment 3 
(Continued) 



if (info->frame_p) 

/* Add PCS + start & ending delimiters, 1 byte each */ 
!2 f ?:i rea I- frame -size = datacnt + fcs length - 
/* 1 nfo->fran,e_si Ze = datacnt * length'p E ad T --length_stri P; y 
info->mac_errors = 

info->crc_a1ign_error - (frm_status & crce); 
if (info->dlci_valid) 
else xmib - setu P-d1ci_parfl!s(info) ; 

info->et_coTlisions = iocb->stats->rx_abort; 
/* call rmon stats collector */ 
xrrn b_col 1 ect_wanstats Cinfo) ; 

piocbSpr^ssld!f r ^^ er - 9et - UPtime ° 1 C ° de Fra9ment 4 
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decap.c 

#define DEBUGCx) ^ 

/* Copyright (c) "., Frontier Software Development, Inc. 

V 



/* Description: 

/* *^ 

/* Contains all functions pertaining encapsulating WAN header & making */ 
/* the packet look like an EThernet frame. 

' Code Fragment 1 
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** function builds the proper protocol frame, adding the Ethernet MAC header. 

PRIVATE VOID build_x25_etpkt(dp, svc) 
N8 *dp; 
SVC *svc; 

N16 length; 
N16 etype; 

wmac->xfptr =0; 

HT0N16 ((TRN16 *) &machdr[4], svc->vc) ; 
etype = svc->protocol ; 

/* first check if this is a multiprotocol vc */ 
if (etype == x25_multi_protocol) 

etype = x25_guess_protocol (dp) ; 
if ( ! etype ) 
return; 

else if ((etype == x25_bay_qllc) II (etype == x25_cisco_QLLC)) 

SAVE_WAN_HDR(dp+2) ; 
--dp; 

memcpy(dp, sna_llchdr, 3); 

lengtn = wmac->wanfsize - wmac->hdrlen + 17; 

PUT_BE_16((TRN16 *) (dp - 2), length); 

wmac->xfptr = dp - 14; 

memcpy(wmac->xfptr , machdr, 12); 

else if (etype == x25_SNA) 

SAVE_WAN_HDR(dp) ; 
dp -= 3; 

memcpy(dp, sna_llchdr, 3); 

lengtn = wmac->wanf si ze - wmac->hdrlen + 17; 

PUT_BE_16((TRN16 *) (dp - 2), length); 

wmac->xfptr = dp - 14; 

memcpy(wmac->xfptr , machdr, 12); 

else if (etype = x25_0Sl) 
{ 

dp -= 3; 

memcpy(dp, osi_llchdr, 3); 
lengtn = wmac->wanf si ze - wmac->hdrlen + 17; 
PUT_BE_16((TRN16 *) (dp - 2), length); 
wmac->xfptr = dp - 14; 

page 23 Code Fragment 2 
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memcpy(wmac->xfptr, machdr, 12); 
else if Cetype == x2 5_bay_ptop) 

SAVE_WAN_HDR(dp) ; 

wmac->xfptr = dp; 
else if Cetype != NULL_PID) 
SAVE_WAN_HDR(dp); 

HTON16CCTRN16 *)(dp-2), etype); 

wmac->xfptr = dp - 14; Code Fraqment 2 

memcpyCwmaoxfptr, .achdr, 12); (Continued) 
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/* 

!; function strips out wan headers, transforms MAC headers and qets 
** encapsulated LAN data for upper layer functions to work on. 

EXPORT VOID strip_wanhdr(datap, length, frame info) 
N8 *datap; 
UINT length; 

xmib_frame_info *frame_info; Code Fragment 3 



EXHIBIT P 



if(datap==0) /* 5.0 */ 



return; (Continued) 
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letScout Systems, Inc. 

westford, ma 01886 
A I i Rights Reserved 



is strictly pi 
this software 



! is part of Licensed material whi'rh i<: th 0 „,.„„„ «. <- 



component of: mib Collector 
Programmer : Danny Lobo 

Description: 

collector f processing ent ^ CaCh1 " 9 functl ' on s to speed up 



Comments : 

History: 
Date 
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export void fastpath_proc e ss_fra m e(XMiB_FRAM E _iN F o *frame_info) 
PP_OUTPUT *pp info- 

UINT i ; 

CACHE_data *free_p; 

CACHE_DATA *p; 
N8 *packet; 
IMPORT BOOL mib_config_ dsmon- 
import BOOL mib_config_hcrt; 
IMPORT BOOL mib_config_art; 

/* Parse the frame. */ 

if (frame_info->ifn != mirror_ifn) 

PP-process frame(frame_info): 

^P_mfo - (pp_output *) frame_info->pp_info; 

e1se { // Handle the mirror ifn 49 Code Fragment 1 
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SHn£ =.j; pp - ou TPUT *) franie_info->pp info; 
pp_info->ifn = mirror_ifn; w - ' 

#if _CDP 

/* Do any cdp processing. 

!! G F N: F ° r 880 °. CDP p£ts are received on rh P 
** Channels ranging from 2048 - 2303 

if C PP-J"fo->1s cdp 44 CCframe_1nfo->1fn < logical_ifn seed) II 
Urrame_info->ifn >= chifn_seed) 44 ~ ; 11 

Cframe_mfo->ifn < chifn_dte_seed))) 

#endif // _cdp col -P roce "-cdpCfra me _info) ; 

/* special fastpath processing for udp and tcp frames only. */ 

if C !Cpp_info->is_tcp || pp_info->is_udp) ) 



Page 5 



EXHIBIT R 



* ****** * J*°\* t ** t * c 
WARNING 



Copyright CO 
Frontier software Development inc. 
Tewksbury, ma 01876 
All Rights Reserved 



distribution is stri ctly prohibi ted h ^ e use - duplication or 

; ownership of this softwaVfis heflby^ransferred 3 "- N ° t1tle t0 and 



COPYRIGHT (c) 



FRONTIER SOFTWARE DEV. INC 



* Module Name : 

* Component of: 

* Programmer : 

* Description: 



* Comments: 

* Revision History: 
vers. Date 



ALL RIGHTS RESERVED 

coletst.c 

NETscout LIC Software 
Ami singhal 

- col_activate_etherstatsf) 

- deactivate_etherstatsO 

- collect_etherstats() 

- retneve_etherstats() 



********************************^^. 
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** coHect_wanstatsO 

** This is the RMON-MIB WAN (ether) stats group collection handler. 

PRIVATE VOID^col 1 ect_wanstats (es , frame_ptr, frame_si 2 e, f rame.status , 

EtherStatsEntry *es ; 
N8 *frame_ptr; 
uint frame_size; 
N32 frame_status; 
N32 frame_time; 
N32 frame_id; 

#ifdef _wan 

N64 *p; 

ETHERSTATS_ENTRY *Es; 
XMIB_FRAME_INFO *info; 

if (frame_time != f rame_time) ; /* these args aren't used */ 
if (frame_id j= frame_id); 

/* 

** Octets & Packets are incremented by frame count amount, since 
** in netflow the frame count may be more than 1, which is default 
** for all other interfaces. 

V 

es->Octets += mibcol_curr_octets; 
es->Pkts += mibcol_curr_pkts; 
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